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Abstract Proper privacy protection in RFID systems 
is important. However, many of the schemes known 
arc impracticaL Some use hash functions instead of the 
more hardware efficient symmetric encryption schemes 
as a cryptographic primitive. Others incur a rather large 
time penalty at the reader side, because the reader has 
to perform a key search over large tag key space. More- 
over, they do not allow for dynamic, fine-grained access 
control to the tag that cater for more complex usage 
scenarios. 

In this paper we investigate such scenarios, and pro- 
pose a model and corresponding privacy friendly proto- 
cols for efficient and fine-grained management of access 
permissions to tags. In particular we propose an effi- 
cient mutual authentication protocol between a tag and 
a reader that achieves a reasonable level of privacy, us- 
ing only symmetric key cryptography on the tag, while 
not requiring a costly key-search algorithm at the rea- 
der side. Moreover, our protocol is able to recover from 
stolen readers. 



1 Introduction 

Radio Frequency Identification (RFID) is a technology 
that allows to wirelessly identify and collect data about 
a particular physical object from a relatively short dis- 
tance (depending on the technology used ranging from 
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a few centimeters up to several meters). The data is 
stored on so-called tags attached to the object, and is 
collected using so-called readers. RFID tags can be very 
small, can be attached invisibly to almost anything, and 
can transmit potentially unique identifying informa- 
tion. Therefore, proper privacy protection within RFID 
based systems is of paramount importance [17,23]. 

Yet RFID is also an enabler for the vision of an 
Internct-of-Things where the physical and the virtual 
become interconnected in one single network. This will 
spark all kinds of applications beyond our current imag- 
ination. Some of these applications may be useful and 
beneficial for individuals and society, others may be 
potentially very damaging (to our personal liberties, 
or otherwise). It would be a waste, however, to abort 
such future innovations by mandating the use of a kill- 
switch on all RFID tags^ that will silence such a tag 
forever once it leaves the shop. Such a kill-switch is a 
very coarse, all-or-nothing approach to protecting pri- 
vacy. It would be far better to develop an approach 
that allows the user to have fine grained and dynamic 
control over who can access his tags, and when. The re- 
search reported on in this paper takes a step into that 
direction. 



1.1 State of the art 

Because of the privacy risk associated with the large 
scale use of RFID tags, many proposals exist to pro- 
vide a certain level of privacy protection for a particu- 
lar application of RFID. We give a brief overview of the 

^ As recommended in EC Recommendation (SEC(2009) 

585/586) of 12.5.2009 on the implementation of privacy and 

data protection principles in applications supported by radio- 
frequency identification. 
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state of the art, focusing on authentication and access 
control. 

Early proposals use relabelling of tag identifiers [•']()] , 
or re-encryption techniques [24,2, 18] that randomly en- 
crypt the identifier from time to time, so that it can 
only be recovered by authorised readers, while being 
untraceable for others. 

Another approach is to implement some form of au- 
thentication between tag and reader, and to allow only 
authorised tags to retrieve the tag identifier. In a public 
key setting this would be easy, but RFID tags are gener- 
ally considered to be too resource poor to accommodate 
for that. Therefore, several identification and authenti- 
cation protocols using hash functions or symmetric key 
cryptography have been proposed [41,12]. In particu- 
lar, Ohkubo, Suzuki, and Kinoshita [32] present a tech- 
nique for achieving forward privacy in tags. This prop- 
erty means that if an attacker compromises a tag, i.e., 
learns its current state and its key, she is nonetheless 
unable to identify the previous outputs of the same tag. 
In their protocol, a tag has a unique identifier idi, that 
is changed every time the tag is queried by a reader. In 
fact, when queried for the i-th time, the tag responds 
with g{idi) to the reader, and sets irfi+i = h{idi) im- 
mediately after that. Dimitirou [lU] presents a similar 
protocol, but that authenticates the tag as well. In both 
cases, if all readers are on line, connected with one cen- 
tral database, the readers can be synchronised and the 
response of a tag can be looked up immediately in the 
database. (Note that the database can keep a shadow 
copy of idi and hence can precompute the next expec- 
ted value g{h{idi)).) If not, or if synchronisation errors 
occur, a search over all possible (initial) identifiers (ex- 
panding hash chains) is necessary. 

In a symmetric key setting the reader cannot know 
the identifier of the tag a priori, or obtain the identi- 
fier of the tag at the start of the protocol because of 
privacy concerns. One can give all readers and tags the 
same symmetric key, but this has the obvious draw- 
back that once the key of one tag is stolen, the whole 
system is corrupted. To increase security, tags can be 
given separate keys, but then the reader must search 
the right key to use for a particular tag. This issue is 
not properly addressed in Engberg's paper [12]. It is 
unclear whether in that paper tags share a single a key 
with a group of other tags, or that each tag has a unique 
and private access key it only shares with the reader. 
The core challenge is therefore to provide, possibly ef- 
ficient, trade offs and solutions for key search and key 
management. Molnar and Wagner [30] (see also [11]) 
propose to arrange keys in a tree structure, where indi- 
vidual tags are associated with leaves in the tree, and 
where each tag contains the keys on the path from its 



leaf to the root. In subsequent work Molnar, Soppera, 
and Wagner [29] explore ways in which the sub-trees in 
their scheme may be associated with individual tags. 
They also introduce the concept of delegation that al- 
lows a tag owner to enable another party to access a tag 
over some period of time, like for instance a fixed num- 
ber of read operations. In another approach, Avoine, 
Dysli, and Oechslin [3,5] show how, similar to the the 
study of Hellman to breaking symmetric keys, a time- 
memory trade off can be exploited to make the search 
for the key to use more efficient. We note that none 
of these systems are practical for RFID systems where 
millions of tags possess unique secret keys. 

Spiekermann et al. [37] observe that although there 
are many protocols and proposals for limiting access 
to RFID tags (either by killing them completely or 
by requiring the reader to authenticate), few systems 
have been proposed that allow effective and fine grained 
control and management over access permissions. The 
RFID Guardian [.!"i] is a notable exception. The main 
idea is to jam all reader to tag communication, except 
for reader requests that satisfy a pre-defined privacy 
rule. This approach has its own shortcomings. For one, 
it is extremely hard to ensure that all reader to tag 
communication is effectively blocked in all cases. More- 
over, tags themselves are not protected at all, leaving 
them vulnerable when the Guardian is out of range or 
malfunctioning. 

We refer to Juels [2-)] (and the excellent bibliogra- 
phy'^ maintained by Gildas Avoine) for a much more 
extensive survey of proposed solutions, and [2()] for a 
more formal analysis of the privacy properties actually 
achieved by some of the proposed authentication pro- 
tocols. 

1.2 On the hardware cost of cryptography 

We base our work on (relatively) new insights regarding 
the amount of hardware required to implement sym- 
metric key cryptosystems as compared to hash func- 
tions. Traditionally, such hash functions are perceived 
to be the most basic (and therefore most efficiently im- 
plementable) building blocks, and hence have been used 
extensively in protocol designs for RFID. This is wrong. 
In fact, the ECRYPT report on light weight cryptogra- 
phy [33] states 

Current standards and state-of-the-art low power 
implementation techniques favor the use of block 
ciphers like the AES instead of hash functions 
as the cryptographic building blocks for secure 
RFID protocols. 

^ WMW.avoine.net/rfid/ 
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Currently there is an AES-128 design with only 3k4 ga- 
tes, which uses 3 /lA at 100 kHz and 1.5 V in 0.35^ tech- 
nology [28,34,15]. Maximum throughput is 9.9 Mbps 
(encryption) or 8.8 Mbps (decryption). A SHA-256 de- 
sign [14,15] that also has been targeted specifically for 
the low end results in 10k9 gates that has a maximum 
throughput of 22.5 Mpbs. Current consumption is 15.87 
/zA at 100 kHz and 3.3 V in 0.35^ technology. Other 
light weight symmetric cipher designs exist as well [S]. 
The quoted AES design is 3 times as small (and thus 
also 3 times cheaper), and consumes less than 10% of 
the power needed by the SHA-256 design, and is only 
about 2.5 times slower in terms of throughput. We use 
these observations to design efficient protocols that in- 
corporate tag and reader authentication with session 
key establishment and fine grained control and man- 
agement over access permissions. Advances in reduc- 
ing the hardware cost of implementing public crypto- 
graphy have also been made. Current implementations 
of (hyper)elliptic curve cryptography require 15,4k ga- 
tes, executing one scalar multiplication in 243 ms when 
clocked at 323 kHz [13,27]. Still the gate count and 
the processing time are much higher than for symmet- 
ric cryptography, making symmetric cryptography the 
preferred choice for lower cost tags. 

1.3 Our contribution 

Our contribution is to propose a model and correspond- 
ing protocols that allow fine grained, effective and ef- 
ficient control over access permissions for RFID tags, 
that respect the privacy of the users. The model is en- 
forced by the tags themselves. The protocols use au- 
thentication as a basic component, and wc propose a 
novel combination of (universal) re-encryption [24,18] 
with symmetric cryptography based authentication [22] 
to obtain a reasonable level of privacy protection with- 
out using public-key cryptography on the tag, and with- 
out the need for the reader to start a time consuming 
key-search algorithm to find the key to use for authenti- 
cation. Although such key-search algorithms are highly 
popular in the research community because of their su- 
perior privacy properties, we believe they are unrea- 
sonable for large scale applications that may involve 
millions of tags (and hence keys) . Finally, our protocols 
are resistant to stolen reader attacks, using techniques 
from [4] . A detailed description of the properties of our 
authentication protocol is presented in Sect. 6. 

The model is quite loosely based on the " Resurrect- 
ing Duckling" paradigm of Anderson and Stajano [■!!), 
38]. Our model is general enough to capture several 
RFID use case scenarios, like supply chain manage- 
ment, ticketing and ambient home intelligence. 



The essence of the model is that a potentially dy- 
namic system of access permissions is defined. We gen- 
eralise the concept of an RFID tag, and view such a 
tag as a container of several data objects on which a 
reader wishes to execute certain functions. Such an ob- 
ject implements a particular application or service on a 
tag, like a customer loyalty program, or a supply chain 
management program (where the on-chip object stores 
the identity of the physical object to which the tag is 
attached) . This extends the notion of an RFID tag con- 
taining just a unique identifier to slightly smarter data 
container, resembling the technology used for the new 
biometric passports [20]. We believe that in the end, 
the idea of only storing a unique identifier on the tag 
and storing all relevant data on the physical object at- 
tached to the tag in a corresponding data record in a 
centralised database is going to prove too limitative in 
the future. For example, for privacy reasons it is better 
to require physical proximity to read the data on the 
tag instead of having that data available in a database 
all the time. We refer to Sect. 2 for more examples sup- 
porting our model. 

Whether the reader is allowed to execute the func- 
tion depends on two constraining factors: 

1. whether the owner of the on-chip object has given 
the reader a permission to execute the particular 
function on the particular object, and 

2. whether the owner of the tag allows the reader to 
access the tag at all. 

The protocols (and the observation that the real chal- 
lenge in RFID privacy lies in allowing controlled use of 
the RFID tag even after the point-of-sale) are inspired 
on the work by Engberg [12]. The first constraint is 
enforced using specially crafted permissions. The sec- 
ond constraint is enforced by the mutual reader-tag 
authentication protocol. This research is part of the 
PEARL'' (Privacy Enhanced Architecture for RFID La- 
bels) project. 

The paper is structured as follows. We first describe 
a few distinctive use cases of RFID and their associated 
requirements in terms of functionality and privacy. In 
Sect. 3 we present our system model. We then show 
how our model captures the essence of the use cases, 
in Sect. 4. We then continue to implement this model 
using data structures (Sect. 5), an authentication and 
session key establishment protocol (Sect. 6) and sub- 
sequent protocols (Sect. 7). We analyse their security 
in Sect. 8 and present some conclusions and further re- 
search in Sect. 9. 
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2 Use cases 

This section describes three use-cases or scenarios, each 
of which focusing on one or more issues that need to 
be addressed by our model. In the next section we lay 
down our model, and then analyse how well the model 
captures the real lifc situations sketched in these use 
cases. 

2.1 Scenario 1 - Supply Chain Management 

As our first scenario, we take the supply chain scenario 
from [12]. In this scenario, we show the need for a proper 
definition of tag ownership and the controlled transfer 
thereof. 

In retail, RFID tags are attached to individual prod- 
ucts after they have been manufactured for the purpose 
of enhancing the supply chain efficiency. Such tags con- 
tain an Electronic Product Code (EPC) that not only 
identifies the type of product as the more classical bar 
codes do, but also includes a number that is unique 
to the individual product. This allows retailers to bet- 
ter keep track of their inventory and counter theft at- 
tempts, and provide better customer service as well. 

Often, for privacy reasons, these RFID tags are zap- 
ped, killed or removed from products at the point of 
sale. This is unfortunate. Many interesting after-sale 
services are possible if the tag allows for a more dy- 
namic and fine grained control of access to it by its 
current owner. For example, it would open the way for 
manufacturers and retailers to store post-sale service 
data onto the tag such as the production run, date of 
sale, warranty data, repair history etc., thus providing 
the them with a possibility for providing more efficient 
en effective service to the customer. 

When a product, such as a TV set, computer, refrig- 
erator etc. needs to be repaired at some point in time, 
its warranty may be voided if it is not repaired by qual- 
ified service organisations. Using the tags as introduced 
above, the manufacturer of equipment installs a service 
object into the tag associated with each of its products. 
In this object, the manufacturer writes all sorts of ser- 
vice data that it does not want to disclose to parties 
other than qualified service organisations. Then, it pro- 
vides read permissions for such service objects only to 
accredited service organisations. 

Many objects change owner during the course of 
their life, consider for example second-hand cars, elec- 
tronic equipment, etc. When the objects change owner, 
so must the attached tags. But any objects on the tag 
(like the service object above) must remain on the tag 
and must keep their data (like the repairs performed on 
the object). 



We can accommodate for this scenario if the follow- 
ing requirements are met. 

— A party is allowed to communicate with a specific 
RFID tag if and only if (a) it is the owner of the 
tag or (b) it is explicitly granted permission by the 
owner of the tag. 

— A party is allowed to access a specific data (object) 
on the tag if (a) it owns the data (object) or (b) 
the data (object) owner has explicitly enabled that 
party to access the data (object) using a specific 
method. In other words, access is assigned for indi- 
vidual method calls on the object. 

— A party that owns a tag must be capable of transfer- 
ring this ownership to another party, without delet- 
ing or changing objects. 

Note that a consequence of transferring ownership of 
a tag is that the set of parties that were allowed to 
communicate with the tag changes drastically, as only 
the owner or a party that has a permission issued by 
this owner, may communicate with the tag. 

2.2 Scenario 2 - Smart Tickets 

Event Services Company (ESC) is large company is- 
suing an advanced, RFID based, smart event ticket- 
ing solution. With the ESC RFID tag embedded in a 
wristband, users can buy tickets for music events on 
line, flash them in their wristband, and prove purchase 
of the tickets at the entry gates of the event. Security 
is important: ticket fraud, and especially black market 
sales are rampant in the ticketing business. Moreover, 
ESC does not want free riders to use its ticketing sys- 
tem: only event organisers with a contract can use it. 

Tom owns such a wristband. In fact, the fashion 
watch he got for his birthday last year contained such 
an ESC tag for free. He regularly buys tickets for soccer 
matches and music festivals on line and appreciates the 
fast and paper ticket less service. Recently, the gay gym 
he visits changed to the ESC service, allowing members 
to book specific slots in the gym in advance. Tom sees 
this as a huge advantage (the gym can be crowded at 
unpredictable times), but is concerned about his pri- 
vacy: he would rather not get his visits to the gym and 
to the soccer matches get connected. Luckily, ESC was 
well aware of these concerns when designing the system, 
and instead of storing the tickets on a central server 
they are all stored on the ESC tag of the user. 

Apart from the requirements from the first scenario, 
this adds the following requirements. 

— Data related to the physical object is stored on the 
tag, and not (necessarily) on a central server. 
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— Permission to install an object may be restricted 
depending on the application (in this case: the tag 
issuer). 

2.3 Scenario 3 - At the Hospital 

In our third scenario, we consider the situation where a 
doctor implants a sensor tag into one of its hospitalized 
patients, e.g. by having him swallow a pill containing 
this sensor tag. In this scenario, we show the need for a 
proper definition of transferal of object ownership. This 
scenario is inspired by the hospital scenario from [39]. 

Consider a patient whose heart condition, respira- 
tion and the like need to be monitored, and a high-tech 
monitoring device exists that acts like a tag as in the 
previous scenario's. Because of price and the fact that 
they are not needed all that often, hospitals own such 
devices, and only a modest amount of them. 

Whenever a patient's condition is to be monitored, 
its doctor can decide to implant such a device into the 
patient, e.g. by having him swallow a pill containing the 
device. Within the body, the sensor starts monitoring 
the patient's condition, filling an object that is specific 
for the sensor. Doing so, a sensitive amount of personal 
data is gathered within the object, and it is part of the 
doctor's job to ensure that privacy is preserved. 

Since the doctor uses the sensor, he must have pretty 
much full control. However, he must also be able to as- 
sign read permission to e.g. nurses. This requires him to 
actually own the object. Note that he should not own 
the device itself, as this would allow him to (dis) allow 
other parties access to other parts of the device as well, 
which, if that results in a catastrophe, will put the 
blame with the hospital. 

We can accommodate for this by adding another 
requirement 

— A party that owns an object must be capable of 
transferring this ownership to another party. 

3 System model 

The system model describes the different entities in the 
system, their mutual relationships, and the operations 
that they can perform on each other. 

3.1 Notation 

We use k to denote a symmetric key, possibly subscript- 
ed to denote its owner, and use s to denote a symmetric 
session key. We use PK for a public key and sk for the 
corresponding private key. Hash functions are denoted 



by h(-). We write © for the exclusive-or operation, and 
; for concatenation of bit strings. {m}k denotes the en- 
cryption of message m with symmetric key k using some 
symmetric cipher, typically AES. [m\k denotes a mes- 
sage authentication code (MAC) for message m derived 
from a symmetric cipher (for instance CM AC [31,7]) 
using key k. Finally, [{'ti}]^ denotes the authenticated 
encryption of m with key fc, for instance by appending 
the MAC of the ciphertext [G]. 

3.2 Tags and readers 

A tag t is a piece of hardware that contains data. At 
the very minimum, tags store a bit string that can be 
read and sometimes written. Usually, tags store several 
values that can be grouped together as tuples because 
of their logical use. More complex, smart card like tags, 
contain ISO 7816 [21] like file structures. We assume 
that for the anti-collision protocol random identifiers 
are used (or else all bets to achieve some level of privacy 
are off). 

We assume readers are at least on-line some of the 
time to obtain fresh data and keys from the central back 
office. 

3.2.1 Classes and objects on tags 

The system model follows the object oriented (00) 
metaphor, so that tags are said to contain objects, each 
of which is a group of bit strings whose structure is de- 
fined by the class that it instantiates. We use o S c to 
denote that object o is an instantiation of class c. For 
every class, each tag contains at most one instantiat- 
ing object. Every class defines a set of methods, each of 
which specifies a kind of operation that may take place 
on objects that instantiate that class. Simple methods 
specify how to read or perhaps write values in a tu- 
ple of a certain type stored on a particular tag. More 
complex cases methods might invalidate a ticket on a 
tag, or increase an electronic purse balance. We write 
/ G c for a method / that is defined for class c. Every 
method is defined in precisely one class. Access to a 
specific method is controlled in one of three ways: 

— the method can be called iff the tag is not owned; 

— the method can be called if the user has an appro- 
priate permission; 

— the method can be called by the domain owning the 
class. 

The 00 metaphor can be applied both to the resource 
constrained case where a tag contains only an identifier 
or a tuple of values, and to the case where complex data 
structures are stored on a tag. 
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3.2.2 The tag management class 

Every tag always contains one instance f2 of the tag 
management class, initially with default settings. The 
tag management class implements functions to manage 
tag access and ownership. This allows us to implement 
tag and class management operations in a similar way 
as methods on ordinary objects, thus simplifying the 
implementation. Details are provided in Sect. 7. 

3.3 Domains and Principals 

We use the term domain to refer to a (legal) entity that 
is capable of bearing responsibilities. Thus, companies, 
organisations and governments are considered to be do- 
mains, as well as individual (adult) persons. We use the 
term principal, or actor, to refer to a resource (e.g. a 
person, or a running application within a computer) 
that is capable of acting on behalf of, c.q. under the 
responsibility of, a domain. While a principal d may 
act on behalf of different domains over time, and the 
change frequency thereof may be very high, we assume 
that at any particular point in time d acts on behalf 
of precisely one domain D. Note that in case of nat- 
ural persons, who can both act as bear responsibility, 
the common practice where a single name is used to 
refer to the person both as an actor and as a domain, 
may cause considerable confusion. Thus, if a principal 
d acts on behalf of a domain Z? at a given point in 
time, then D is responsible for everything that d does 
at that time. Since the domains bear the responsibili- 
ties, we have no compelling need to distinguish between 
the various principals that may act on behalf of a given 
domain, and thus we assume every domain to be inhab- 
ited by exactly one principal. We use T> to denote the 
set of all domains. 

3.4 Ownership 

We use the term owner (ship) to refer to the respon- 
sibilities associated with controlling tags, objects, etc. 
Since responsibilities are born by domains, ownership 
can only be assigned to domains. Ownership can be 
transferred by the owning domain to another (accept- 
ing) domain. 

Thus, the tag owner for a tag t is a domain that 
bears the responsibility for controlling access to t, i.e. 
for issuing and revoking the associated permissions. Also, 
it controls the permissions associated with other tag re- 
lated functionality, such as the creation of objects or the 
transferal of tag ownership. We use T to denote a tag 
owner and T to denote the set of tag owners, so T e T 



and T ^ T). We write t £ T to indicate that tag t is 
owned by T . 

The class owner is responsible for controlling access 
to objects that instantiate this class, i.e. for issuing and 
revoking permissions for executing methods defined by 
that class. We write c G C to mean that class c is owned 
by domain C (i.e. its class owner). 

Note that if a class owner C owns a class c, then 
(initially) it also owns every object o G c. Thus, ob- 
ject ownership is (initially) implied by class ownership. 
However, ownership of individual objects may be trans- 
ferred to other domains later on. If that happens, the 
class owner is not necessarily the owner of all objects 
of that class. 



3.5 Permissions 

Every permission, i.e. the right to access a tag or the 
right to execute a method on an object, is issued by 
the domain that owns the tag or the object. Also, per- 
missions are issued to domains rather than to princi- 
pals, because domains can bear responsibilities associ- 
ated with using such permissions, which principals can- 
not. In our model, a permission that has been issued to 
a domain can be used by any principal that acts un- 
der the responsibility of that domain. Consequently, if 
misuse of a permission can be traced back to the do- 
main the permission was issued to, this domain can be 
held accountable. It is outside the scope of this paper 
whether or not a domain limits the use of permissions 
that it has been assigned to a subset of the actors acting 
on its behalf, or sanctions misuse thereof. 

One of our main contributions is the distinction we 
make between accessing (i.e. communicating with) tags 
and accessing (i.e. executing methods on) objects on a 
tag. A consequence of this distinction is that it requires 
two rather than one permission to access an object on 
a tag: one permission is needed for accessing the tag 
on which the object is stored (which is granted by the 
tag owner), and the other permission is required to ex- 
ecute the appropriate method on that object (which is 
granted by the object owner). Moreover, these permis- 
sions are implemented quite differently (as described in 
more detail in Sect. 5.3 and 6). The first permission is 
checked using a mutual tag-reader authentication pro- 
tocol, which verifies that the reader domain occurs in 
a list of permitted domains. The second permission is 
implemented using a permission token that encodes the 
permission to access a particular method on an object. 
Thus, manipulation of an object on a tag is controlled 
both by the tag owner and object owner. 
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3.6 Operations on a Tag 

Operations are performed by actors (readers) acting on 
behalf of a domain. Operations can only be performed 
when the actor acts on behalf of a domain that has per- 
mission to do so. While other operations are certainly 
conceivable, we consider only the limited set of basic 
operations as specified in Sect. 7. 

The most basic operation the model must support 
is calling a method on an object of a certain class sto- 
red on a particular tag. For this, two permissions are 
required: first, the domain must be allowed to access 
the tag, and secondly the domain must be allowed to 
execute the method on (the class of) the object. Note 
that access to a method is initially granted at the class 
level. So access rights for a particular method initially 
apply to all objects of that class. 

The creation of permissions is done off-tag, as is 
the distribution thereof*. Tag ownership is controlled 
through the following functions: 

— TakeTagOwnership: Set a specific domain as the 
tag's owner. Can be executed by any domain as long 
as the tag is not owned. 

— TransferTagOwnership: Transfer ownership of a 
tag from its tag owner to another domain. Can only 
be executed by the owner of the tag. 

— RelinquishTagOwnership: Relinquish ownership 
of a tag so that the tag is no longer owned. Can only 
be executed by the owner of the tag. 

Tag access is controlled through the following functions: 

— GrantTagAccess: Allow a specific domain to ac- 
cess a tag. 

— Revoke Tag Access: Disallow a specific domain to 
access a tag. 

These functions are only executable by the tag owner. 

Object management is controlled through the fol- 
lowing functions: 

— InstallObject: Create an object and set the class 
key. Can only be executed by the tag owner, or any 
domain with a permission issued by the tag owner. 

— UpdateObject: Overwrite the contents and the 
code of an object. Can only be executed by the class 
owner, or any domain with a permission issued by 
the class owner. 

— UpdateClassKey: Change the class key associated 
with an object. Can only be executed by the class 
owner. This function can (also) be used to transfer 
ownership of objects. 

* The word 'capability' might be more appropriate than the 
word 'permission'. 



— DeleteObject: Destroy an object and its associ- 
ated class key. Can only be executed by the class 
owner, the tag owner, or any domain with an ap- 
propriate permission issued by the class owner. 

As said before, this paper only describes a basic set of 
operations that will allow us to implement the scenarios 
from Sect. 2. Other operations are certainly possible 
and can easily be added to the model and implemented 
in a similar fashion as the basic operations. 

4 Analysis 

The system model from Sect. 3 should allow us to im- 
plement a large set of common privacy friendly uses of 
RFID technology. To capture these use cases, we sketch- 
ed three different scenarios in Sect. 2. We now briefly 
verify that our model indeed allows us to implement 
these three scenarios. The security and privacy proper- 
ties are analysed after we have presented the protocols 
that implement the operations - they do not depend on 
the model, but on the actual implementation. 

4.1 Mapping of Scenario 1 

Product tags that comply with our model would be 
attached to the product when manufactured. For ev- 
ery product type that a manufacturer M produces, M 
defines an object class Service that contains data and 
access methods that is relevant to the manufacturer, 
including a.o. production data, production plant, serial 
numbers and so on. First, M takes an unowned tag and 
takes ownership thereof (executing the tag's function 
TakeTagOvifnership). Tag owners can then execute 
InstallObject, which is what M uses to create the Ser- 
vice object on the tag. For each of the methods on this 
object, M creates permissions (see Sect. 5.3) that M 
assigns to itself so that it can access all methods it- 
self. Note that M only needs to create such permissions 
once, as they will be usable on every Service object M 
creates. 

To accommodate the service-organisation scenario, 
all that M needs to do is create a read-permission for 
Service objects for every organisation that it has ac- 
credited for servicing M's TV sets, and send this per- 
mission to the appropriate organisation in a secure man- 
ner. This way, only accredited organisations (and M) 
may read Service objects. Note that service organisa- 
tions cannot yet read the Service objects since they do 
not have permission to access the tag itself. This is done 
later when the consumer becomes the tag owner. 

Whenever a retailer R sends M an order for a num- 
ber of TV sets, M prepares the delivery. For every tag 
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in this delivery, M first writes appropriate data into 
the Service object so that it says to which retailer it 
will be delivered, as well as other information M might 
later need. Then, M transfers ownership of the tag to 
R (TransferTagOvifnership, which means that M no 
longer is capable of accessing the Service object because 
it can no longer access the tag (see Sect. 7.2 for details). 
Still, M's service object remains on the tag and all per- 
missions that it has issued to itself and the accredited 
service organisations remain valid. Then, M sends some 
data to R in a sufficiently secure manner, thus enabling 
R to gain ownership of the tags (See Sect. 7.2). While 
the shipment is in transit, only M and R can take con- 
trol of it as they have the data to regain ownership. For 
anyone else, the tag is useless as they cannot commu- 
nicate with it. 

For use in its retail processes, R has already de- 
fined an object class Retail, and like M, R has created 
and distributed permissions for Retail objects to itself, 
and other domains as necessary. Thus, when R receives 
the data that M has sent as well as the shipment, R 
can take control of each tag, and create a Retail ob- 
ject on each of them, filling it with data relevant to 
R's retail process. Note that the tags still contain Ser- 
vice objects, but R can only access such objects if it 
has been issued appropriate access permissions, i.e. if 
R is a service organisation that M has accredited. Also 
note that R controls whether or not M can access its 
own service object, as M needs tag-access permissions 
which R can grant (GrantTagAccess) or deny (e.g. 
revoke using Revoke Tag Access). 

When a customer C buys a TV set, R updates its 
service object and subsequently transfers ownership of 
the tag to C. C may subsequently grant R and M ac- 
cess to the tag, that would allow them to work (only!) 
with their own service objects (and objects for which 
they have been issued a permission by the correspond- 
ing class owner). Also, C can install a data object of its 
own on the tag provided an appropriate class has been 
defined and permissions created. Also, C can resell the 
TV set to C and simply transferownership of the tag 
to C. 

If C is not interested in managing the tag, then R 
may safely keep tag ownership as no other domain than 
R (and perhaps M) would be able to use the tag, and 
still then only using their own data. A more difficult sit- 
uation is if C had taken up tag ownership, but sells it 
to a party C that is not interested in taking tag owner- 
ship. While we think there may be several solutions 
here, we leave this case outside the scope of this paper. 
Thus, throughout the lifetime of a tag, each owner M, 
R, or C has full control over who can use the tag and 



who cannot. Also, M, R, or C can install their own data 
the confidentiality of which is under their own control. 

4.2 Mapping of scenario 2 

In this scenario, ESC (Event Services Company) is the 
first to take ownership of the tag using TakeTagOwn- 
ership. Using the default (known) class key of the tag 
management object I?, it creates a permission to call 
UpdateClassKey to set the class key of f2 to its own 
secret value. This key is used to create permissions for 
every event organisation that has a contract with ESC, 
to install objects through f2 using InstallObject. 

ESC transfers ownerships to consumers buying ESC 
tags using TransferTagOwnership. Now users buy- 
ing tickets from certain organisations first grant access 
to the tag for these organisations through GrantTa- 
gAccess. These organisations then install their own 
ticket object calling InstallObject with the relevant 
ticket data on the tag. They need permission from ESC 
(as described in the previous paragraph) to do so. 

4.3 Mapping of Scenario 3 

With our model, we can show how in scenario 3 owner- 
ship of objects can be transferred between parties. 

We start out with a doctor D that works at a hos- 
pital H which has a patient P and a nurse N. H owns 
a high-tech monitoring tag (device) T, which contains 
at least one object being of the class Tmon which has 
methods implementing all sorts of monitoring functions. 

When D decides to implant T into P, D becomes 
responsible for the use of functions of the Tmon object. 
While it is undesirable to transfer ownership of T to 
D, it is desirable to transfer ownership of the Tmon 
object from H to D because this allows D to control 
who may use which function of the Tmon object. Thus, 
when D borrows T from H, H transfers ownership of 
the Tmon object to D (issuing a permission to D to call 
UpdateClassKey on Tmon). This immediately makes 
all existing permissions obsolete that H has assigned to 
any domain for this particular Tmon object. However, 
such permissions remain valid for all Tmon objects that 
H still owns. 

Now, D can issue permissions to the Tmon object, 
e.g. to nurse N that nurses the patient. 

When P is dismissed from the hospital, T is removed 
from P, and ownership of the Tmon object is returned 
to the hospital. This immediately invalidates the per- 
mission that N has for the Tmon object. However, as 
long as the validity period of this permission has not 
expired, N can still use it to access Tmon objects on 
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other tags (provided N has access to the tag (which 
is controlled by the hospital) and the Tmon object is 
owned by D. 

5 Data structures 

In this section we describe the data structures stored 
by the tags, and the keys and permissions used by the 
domains to access the data on a tag. In the next section 
we describe the implementations of the operations that 
can be performed on a tag. 

5.1 Keys 

To implement permissions, the system uses the the fol- 
lowing types of keys. Some keys (the domain key pairs 
PKjj, skjj) are asymmetric keys, the other keys are 
symmetric keys. 

Tag access keys ka- Access to tags is controlled using 
tag access keys ka- These keys are unique to a tag, 
and derived from the tag identifier t using a mas- 
ter access key fc^ through key diversification [i ] by 

ka = {t}kA- 

Master access keys kA- Each domain has a master ac- 
cess key kA- Readers in a domain use this master 
access key fc^ to derive tag access keys from tag 
identifiers. Each tag thus stores, for each domain 
that is allowed to access it, a different tag access 
key. 

Domain key pairs PKd, skjj. Each domain keeps a uni- 
que ElGamal public/private domain key pair PKdi 
sko- These keys are used in the authentication pro- 
tocol to preserve privacy of the tag identifier t. To 
thwart stolen reader attacks, readers get a new pair 
of keys every once in a while. These keys are stored 
in the array E\\. 

Class keys kc- For each class there exists a unique class 
key kc- The class key is used to encode access per- 
missions to the class methods. A tag stores, for each 
object, the corresponding class key to verify such 
permissions. Class owners know all the class keys of 
the classes they own. Changing the class key of an 
individual object can be utilised to transfer owner- 
ship of that particular object. Conceptually, how- 
ever, this makes the object member of another class 
(albeit with the same structure and methods as the 
class it originally was a member of). 

5.2 Other data stored on the tag 

A tag t also performs a bit of bookkeeping. Firstly, it 
records a time stamp nowt that approximates the cur- 



rent date and time (see below), initially — cxo. Tags also 
store several objects, each of a class c together with the 
key^ kc- Also, a tag t keeps an access set At that stores, 
for each domain D that is granted access to the tag, the 
following three items. 

— An encrypted tag identifier id, equal to the ElGamal 
encryption (t • PKfj,g^) of the tag identifier t. 

— The epoch e in which the encrypted tag identifier 
was created (for explanation see Sect. 6). 

— The diversified tag access key ka, which equals {i}fe^ 
for the master key kA used by domain D. 

— A boolean flag indicating whether this domain is the 
owner of the tag. 

We interpret the access set as a dictionary indexed by 
domains (as a domain can have at most one such tuple 
in the access set), and write At[D] = {id,ka,b)- There 
is at most one domain that is the owner of the tag. We 
write ownert for that domain (which equals _L if the 
tag is not owned by a domain). Initially, At = 0. 

Finally, the tag stores the current session key s, 
which initially and in between sessions equals a default 
value (denoted _L, but which actually is a valid key), 
and which is set to a certain value as the result of a 
successful mutual authentication (in which case the au- 
thenticated reader holds the same session key). It also 
stores the domain of the reader that was authenticated 
in r (which equals -L in between sessions). 

We usually omit the subscript from now, owner and 

A. 



5.3 Permissions 

To grant a domain D access to a method / on an object 
of class c up to time A, the class owner C generates a 
permission token 

kcj,D,A = {f,D,A}k^ 

and sends this to the domain D. This permission token 
expires as soon as the current time exceeds A- Tags use 
now as their estimate of the current time to verify this. 
This is updated after each successful call of a method 
on the tag (which includes the current time as asserted 
by the caller) . It is also set to the current time when the 
first domain takes ownership of the tag. A similar me- 
thod is also used by the European RFID passports [9, 
20]. 

^ This is a weakness that seems to be unavoidable: the owner of 
the tag can in principle recover the class key; the install procedure 
should ensure that the key cannot be captured in transit. 
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6 Mutual authentication and establishing a 
session key 

A basic step underlying the protocols that implement 
the operations that access a tag, is to mutually authen- 
ticate a tag and a reader, and to establish a session key 
among them^. 

Below we present a protocol that is cfBcicnt for both 
the reader and the tag. In principle it combines ele- 
ments of three different known authentication proto- 
cols to strike a balance between tag and reader effi- 
ciency, achieve a robustness against a reasonably large 
class of adversaries, and achieve a certain level of pri- 
vacy as well. In fact it combines a standard, ISO/IEC 
9798-2 [22] based symmetric key authentication proto- 
col, with (universal) re-encryption [24, 18] to avoid the 
costly key search, and a counter based approach to in- 
validate keys from stolen readers [4] . To further enhance 
privacy, users may perform a separate re-encryption of 
all identifiers on a tag at any time. 

To be precise, the protocol achieves the following 
properties 

mutual authentication The reader and the tag arc mu- 
tually authenticated. 

soft privacy Tags can only be traced in between two suc- 
cessful re-encryptions (including the re-encryption 
performed during an authentication). Except for the 
reader performing the re-encryption, no other rea- 
der or eavesdropper can link the presence of the tag 
after the re-encryption with an observation of this 
tag before the re-encryption. 

owner- controlled privacy Tag owners can re-encrypt all 
tag identifiers for all domains at any time on the 
tags they own. 

resilience to tag compromise Tags do not contain global 
secrets. Hence a tag compromise does not affect any 
other tags in the system. 

resilience to reader compromise Stolen readers (or oth- 
erwise compromised readers) will not be able to re- 
cognise or access tags, once those tags have been 
in contact with another valid reader after the com- 
promise [4]. A similar property is achieved by the 
European biometric passports [9,21)]. 

reader efficiency The reader performs a constant num- 
ber of operations. 

® Actually, from a privacy perspective, we are only interested 
in authenticating the reader. Only after the reader is proven au- 
thentic, and has permission to access the tag, the tag has to 
identify and authenticate itself. However, since we are unable to 
use public key cryptography on the tag, and we do not wish to 
store global shared secrets on the tag, we are left with using key 
diversification based on the identity of the tag. Hence authenti- 
cating the reader as well as the tag simultaneously seems to be 
the only way forward. 



tag efficiency The tag performs only a constant number 
of symmetric key cryptography operations. 

The protocol we present below explicitly checks the 
correctness of the responses, that may contain addi- 
tional information for that purpose, to positively au- 
thenticate the other party. Another option is to rely 
on implicit authentication through the session key that 
is established as well: if the authentication fails, both 
parties will have different values for the session key, and 
therefore subsequent protocol steps will fail. 

Note that in the description of the protocols we do 
not explicitly describe the behaviour of a principal if 
it detects such an error. Instead we use the convention 
that if an internal check fails, the principal continues to 
send the expected messages at the appropriate times, 
with the appropriate message format, but with random 
message content. This is necessary to preserve privacy, 
as observed by Juels et al. [2-5,26]. 

Our protocol (see Fig. 1) is an extension of the the 
ISO/IEC 9798-2 [22] standard, using diversified keys [1] 
to avoid sharing keys over many tags^. The tag stores 
such a diversified tag access key A:^ that corresponds to 
{t}kA - To compute this diversified key from the master 
access key Ua it stores, the reader needs to learn the tag 
identifier t. This cannot be sent in the clear for privacy 
reasons. The solution is to encrypt the tag identifier t 
against the public key of the reader to obtain id, and let 
the reader re-encrypt [24] that value with every authen- 
tication run. This way the tag does not have to perform 
any public key operations. Note that the re-encrypted 
value is only used as the new tag identifier after a suc- 
cessful authentication of the reader. This avoids denial- 
of-service attacks. Finally, the re-encryption keys stored 
by the readers are updated every time a reader is stolen. 
Every time this happens, a new epoch is started. Stolen 
readers no longer receive keys for future epochs. Tags 
that authenticate successfully, receive a new encrypted 
identity, encrypted against the most recent epoch key. 
This makes it impossible for compromised readers to 
track this tag. 

Note that corrupt readers can update the tag identi- 
fier to an arbitrary value. If that value is not recognised 
as a tag identifier by a genuine reader in a next authen- 
tication run, this reader will send random data to the 
tag. The tag will detect this and set A[D] := L. The tag 
will then stop responding to requests from this domain. 
Without this countermeasure, the arbitrary value for 
the identifier would never change and the tag would be 
traceable forever. 

^ The first encrypted message is also protected by a MAC, 
because the contents of the message should not malleable while 
keeping the response to the challenge intact. This is not guaran- 
teed if one only encrypts the message, e.g., in ECB mode. 
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Reader d a D 



Tag t 



input; epoch keys 

access key kj\ 
current epoch t 

state: & is current datetime 

({u,v), (y,z)),e',r' 
verify e' < e 

{sko,PKo) ■■= Ele'] ; verify y/z'''=o = 1 
t' := u/v^'=o 
iskD,PKn)=Ele] 
generate random x,x' 
u' := t' ■ PKfy mod p 
v' := mod p 
y' := PKfy mod p 
z' := mod p 
id' :={iu',v'),{y',z')) 
ka ■■= {t'}k^ 

generate session key s and random q 



decrypt using ka into q",s' 
verify q = q" 
return {s<Ss',t') 



[{td';t;r';q;S;s}]k^ 



state: access set A[], 

current datetime estimate now 

D' 

(id,e,k'a,h) := A[D'] 
generate random r 



-4 decrypt using 

k'a into id" ,e" ,r" ,q' ,5' ,s' 
A[D'] ■= ± 

verify r = r" and now < <5' 

now := <5' ; A[D'] := {id", e", fc^, 6) 

generate session key s 
return {s' ®s,D') 



Fig. 1 Authentication and session key agreement. 



The protocol can be extended using ideas from Hoep- 
man et al. [19] by storing so called authentication credit 
on the readers, that cannot be used to generate valid 
authentication responses. This way, readers do not need 
to store master keys, and therefore need to be less trust- 
ed, or can be operated in less trusted environments. 

At the reader side the protocol returns the tag iden- 
tifier and the session key to be used. For a call to such an 
authentication protocol run in the protocols below we 
write AuthenticateR{sk]j, PK]j,kA)- At the tag side, 
the protocol returns the session key, as well as the au- 
thenticated domain. We write AuthenticateT{) for this 
call. 

6.1 Re-encryption 

The protocol uses re-encryption, or rather universal re- 
encryption [18], as follows. We use the ElGamal encryp- 
tion scheme [l(i] over a cyclic group G of order q. To 
be concrete, and to achieve semantic security [40], we 
choose two primes p and q such that q\\{p— 1) (i.e., q is 
a divisor of (p — 1)) and choose as G the cyclic subgroup 
of Zp with order q, and pick a generator g for G. These 
are global, system wide, constants. 

Each domain has, for each epoch, its own public/pri- 
vate key pair {PKjj, ska) where skn is a random in- 



teger between 1 and q — 1, and PKd — g'^'^" . The tag 
identifier t is encrypted, using ElGamal, as 

(u,z;) = (t-PA-,5-) , 

where a; is a random value in [0,q — 1]. To allow re- 
encryption by readers that do not know the correspond- 
ing private key, each tag stores with each encrypted tag 
identifier a corresponding re-encryption factor 

(y,z) = (FA'^',5^') , 

where x' is a new random value in [0, g — 1]. Note that 
this is basically an encryption of the value 1 against 
the same key. Because ElGamal enjoys the homomor- 
phic property that the multiplication of the encryption 
of two ciphertexts equals the encryption of the multi- 
plication of the corresponding plaintexts, we see that 
{uy, vz) in fact equals the encryption of tag identifier t. 
The encrypted identifier now becomes 

id ^ {y,z)) . 

Readers store the key pairs for the epochs in an 
array EW, storing the keys for epoch e at E[e]. This 
array is filled with epoch keys up to and including the 
current epoch e, and grows in size over time. 
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To re-encrypt, a reader that knows the correspond- 
ing, most recent public epoch key PKu does the follow- 
ing. It generates new random values a and a' in [0, q— 1] 
and computes 

and 

and sends 

td' ^{{u',v'),{y',z')) 

to the tag. Readers that do not know the current epoch 
key can use the re-encryption factor to compute a new 
encrypted identifier as follows. Again two random fac- 
tors a and a' in [0, 9 — 1] are generated, and then the 
reader computes 

{u',v') = {u-y-,vz-) 

and 

(y',z') = (/,z'^') 
and again sends 
id' = ((u\v'), {y',z')) 
to the tag. 

Requests to re-encrypt other encrypted tag identi- 
fiers can be issued by authorised readers to the tag man- 
agement object, see Sect. 7.4. Typically, readers that 
are owned and operated by a tag owner will have the 
permission to perform such re-encryptions. This way, 
owners of tags have control over how easily their tags 
can be traced. Without universal re-encryption, only 
readers knowing the public key of the domain can re- 
encrypt. If a tag is hardly ever accessed by such a reader 
(consider for example a supply chain tag attached to a 
piece of clothing that is never accessed again after the 
point of sale) , such a tag is principle unlimitedly trace- 
able. By frequently re-encrypting their tags, users can 
make such tags much less traceable. 

To decrypt, one simply verifies that y/z''*^" = 1 and 
computes u/u"*^" , using the appropriate epoch key sto- 
red in To avoid the need to search for the right key, 
the tag sends, together with is encrypted identifier, the 
epoch in which it was last updated^. 

* This impacts privacy, in particular it allows one to trace tags 
that are infrequently used and hence broadcast old epoch num- 
bers. However, in the current protocol that is not a separate con- 
cern, as the same tag will broadcast the same encrypted tag iden- 
tifier until it is successfully updated (in which instance its epoch 
will be set to the most recent epoch, which contains a large num- 
ber of tags). 



6.2 Alternative approaches 

In the course of developing the above algorithm, we 
have considered various alternatives. The main draw- 
back of the above protocol is that tags are traceable 
in between re-encryptions. Every malicious reader that 
claims to be from domain D will receive the current 
encryption of the identifier. This can be solved in two 
ways, both incurring another, more severe, drawback. 

The first option is to let the tag (instead of the rea- 
der) do the re-encryption each time it is queried by a 
reader. Then the tag is no longer dependent on a rea- 
der to provide it with a proper re-encryption, and mali- 
cious readers no longer pose a threat. But this requires 
that the tag is capable of performing modular expo- 
nentiation at reasonable speed. This is out of scope for 
low cost tags. Moreover, if the tag can do that, then 
one might as well use an authentication protocol us- 
ing asymmetric cryptography. Such a protocol would 
be much simpler than our current proposal. 

The second option is to stop responding to requests 
from domain D after a fixed number of times, unless one 
such request was a full run of the authentication proto- 
col that updated the current encryption of the identi- 
fier. This limits the time a tag can be traced, but makes 
the system vulnerable to denial of service attacks. 

Finally, we considered another approach where the 
tag would randomly encrypt its tag identifier to a sym- 
metric domain key fcu, sending 

to the reader at the start of the authentication proto- 
col^. By including the random r, the whole message is 
randomised, and tags become untraceable. However, ko 
is stored on all tags accessible by domain D. Because 
tags are not tamper proof, this key is not protected and 
will become known after some time. From that time on, 
these tags become traceable and privacy is lost. 

7 Protocols 

Below we will describe protocols that implement the 
operations from Sect. 3.6. We take a rather generic ap- 
proach. Instead of implementing special protocols for 
each of these operations, we in fact model all these oper- 
ations either as calls on normal objects (DeleteObject 
and UpdateObject), or as special methods of the tag 

^ This message should not be encrypted in ECB mode, but in 
CBC mode (if the nonce and the tag identifier together do not 
fit inside a single block). The point is that the random value r 
preceding the tag identifier should randomise the encryption of 
the whole message, in particular the encryption of t, to preserve 
the privacy of the tag. 
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management object J7 (all other operations). That is, 
we present pseudocode for the body of each of these 
operations as if they were methods of a certain object, 
operating on the state of the object and or operating 
on the state of the tag. 

This way, the only 'protocol' that we need to de- 
scribe now is how to securely call a method on an object 
stored on a tag. In fact, this protocol is split in three 
sub-protocols. The first sets up a session and a shared 
session key, the second securely calls the method using 
the session key to secure the channel and using permis- 
sion tokens to verify the legitimacy of the request, and 
the third closes the session. 

Note (cf. Sect. 6) again that we do not explicitly 
describe the behaviour of a principal if it detects an 
error. 



7.1 Calling a method 

To call a method / on an class c, the reader d belonging 
to domain D and the tag t first set up a session using 
the protocol in Fig. 2. This is nothing more than start- 
ing the authentication protocol from Fig. 1. If this is 
successful, the reader and the tag share the same ses- 
sion key. Both initialise their message sequence counter 
(m and n) to 0. 

The actual method call follows the protocol in Fig. 4. 
This protocol can be executed several times in a row, to 
execute several methods within a single session. Each 
message includes the current value of the message coun- 
ter, and each message is encrypted and MAC-ed with 
the session key. The message counters are incremented 
with every subsequent message within a session. The re- 
ceiver verifies the included message counter to prevent 
replay attacks. 

For each method call, the reader sends the corre- 
sponding permission token, which is verified by the tag 
using the class key k'^ of the class whose method is 
called. It also verifies whether the permission token is 
still valid, using its own estimate of the current time 
now, and whether the permission token is bound to the 
domain that was authenticated in the first phase. Then 
the reader sends the method call parameters, and the 
tag responds with the method result. If the method is 
supposed to return no result, a random value is sent 
instead. Note that the method is called with the name 
of the calling domain as the first parameter. 

To call a method on an object for which no permis- 
sion tokens are necessary (which is the case for some of 
the methods of the tag management object, see below), 
basically the same protocol is used. In this case how- 
ever, the caller does not have to send a permission to- 



Reader d a D 
input: keys fc^, E[] 
epoch e 
{s\t'): = 



Tag t 



{s,r): 



AuthenticateR{E[], kA, ^) AuthenticateT () 

n := m := 



Fig. 2 Setting up a session. 



Reader d a D 

session key s' 



[{stop}]^ 



Tag t 

session key s 

decrypt and verify using s 
s := ± 
r := ± 



Fig. 3 Closing a session. 

ken, and the tag only verifies that the requested method 
on that object is indeed callable without permission. 

Finally, to close a session, the protocol in Fig. 3 is 
executed. 



7.2 Tag ownership functions 

The following methods on the tag management object 
Q implement transfer of ownership. To relinquish owner- 
ship of a tag, the tag owner can execute the following 
method. 

RelinquishTagOwnership ( caller ) : 
verify owner — caller ; 
A := % (hence owner ■ 
s := _L. 



The functionality of RelinquishTagOwnership may 

be extended to include the deletion of all objects (other 
than the tag management object), and the resetting of 
information in the tag management object. 

To become the owner of an unowned tag, a domain 
calls the following method 

TakeTagOwnershipfcfflZ/er, D, id, ka) '■ 
verify owner = _L ; 
A[D] := {id, ka, true) ; 

where the caller of TakeTagOwnership from domain 
D has received the tag identifier t out-of-band. He then 
generates a random x, computes id ~ (u, v) ~ {t ■ 
PKfj,g^) and computes ka = {t}kA using its own mas- 
ter access key kA, before calling the method. Note that 
this protocol is susceptible to hijacking and eavesdrop- 
ping on the new owner's access key, if the default session 

If so desired, resetting of A can be skipped. However, in that 
case the owner flag for F must be reset. 
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Reader d £ D 

session key s' 
permission token fcc,/,D,zi 
counter n 



decrypt and verify using s' 
into m', r 
verify m' = n + 2 
n := n + 3 



l{n:c:f:A;p}]^ 



[{n-\-l;parameters}] 



[{m + 2;resuU}]s 



Tag t 

session key s 
calling domain F 
counter m 

decrypt and verify using s 

into n',c'J',A',p' 

verify now < A' 

verify n' = m 

look up object of class c' 

and keep k'^ 

verify p' = {/',r,Z\'}fc, 

decrypt and verify using s into n' , x 
verify n' = m + 1 

execute f{r,x) 



Fig. 4 Calling method / on class c using permission token k^ j jj^ valid until A. 



key _L is used (which is the case when the tag has no 
owner). 

To transfer ownership of tag t from tag owner T to 
domain T', a new entry for the new tag owner must 
be set in A with a new encrypted tag identifier and a 
new diversified access key (and in fact aU other entries 
in the access set need to be deleted) . The tag identifier 
does not change. This process is in fact a three party 
protocol that is implemented by two method calls. The 
first runs as follows. 

TransferTagOwnership ( caller ) : 
verify owner = caller ; 
j4 := (hence owner = 1.) ; 

Note that this function can only be executed in sessions 
of the authentic (ated) tag owner. After execution of this 
function, the session is not terminated (i.e. the session 
key is not reset). While in this state, the tag is shipped 
to the new owner T' and the values of the tag identifier 
id, the session key s and the message counter n arc sent 
to T' out of band. Then, T' calls TakeTagOwnership 
(without prior authenticating and hence starting a new 
session!), thus becoming the new tag owner (preferably 
when the old owner is out of reach so it cannot eaves- 
drop on the new values sent to the tag). 

We note that the above described method might 
pose problems for domains that need to take owner- 
ship for many tags, as e.g. electronics manufacturers or 
retailers may do (see Scenario 1). They would face a 
practical problem of how to determine which tag would 
be associated to which tag identifier and which session 
key to use, which could easily become an adminstrative 
nightmare. Also, it would be more in line with Ander- 
son's Duckling protocol [39,38] if anyone can just take 
ownership of an unowned tag without any other knowl- 



edge. For unowned (and unowned only) tags one could 
enable a method that returns the unencrypted tag iden- 
tifier. To transfer the ownership of many tags using a 
single session key, one could extend the method trans- 
ferTagOwnership with an additional parameter s to 
set the session key on the tag to a fixed value. 

7.3 Granting access to a domain 

To grant a domain D access to a tag t, its access set 
entry At[D] needs to be set with a new encrypted tag 
identifier and a new diversified access key. This process 
is again a three party protocol that is implemented by 
two method calls. None of these methods require addi- 
tional permission tokens to be executed. The first me- 
thod called (by the tag owner) is 

Gr antTagAccess( caller , D) : 
verify owner = caller ; 
A[D] := ± ; 

The tag identifier, the value of the session key as well 
as the value of the message counter n are sent to the 
domain D out of band. He subsequently calls {not au- 
thenticating and starting a new session!) 

AcceptTag Access (^caZ/er, D, id, ka) : 
verify A[D] = ± ; 
A[D] :~ (id, ka, false) ; 

computing id = {u,v) = {t ■ PKf),g^) and ka = {t}kA 
as in the case of TakeTagOwnership. Note that the 
remarks made for TakeTagOwnership with respect 
to the need to communicate the tag identifier, apply 
here equally well. Also, an improvement to these func- 
tions can be made if it would not be necessary to have 



15 



a pending session in between the calling of GrantTa- 
gAccess and AcceptTagAccess as a refusal to exe- 
cute Accept Tag Access would constitute a denial of 
service. 

RevokeTagAccess ( caller, D ) : 
verify owner = D ; 
A[D] := ± ; 

7.4 Re-encrypt identifiers 

The following two functions allow a reader to re-encrypt 
all encrypted tag identifiers stored in A. First the rea- 
der retrieves the current encrypted tag identifiers in an 
array through the following method. 

ReEncryptGetlds ('caZferj : 
verify owner ~ caller ; 

return a list of all encrypted tag identifiers in A ; 

The reader then computes the re-encryption of each of 
the entries in A as described in Sect. 6.1, creating a new 
array R. Finally, to upload the new entries to the tag, 
it calls the following method. 

ReEncryptPutlds ( caller ,R) : 
verify owner = caller ; 

store each entry in R in the corresponding location 
in A ■ 

Both methods can only be called by the tag owner. 
Alternatively, one could require that the caller owns a 
permission token to call the method. 

7.5 Managing objects 

Managing an object involves the creation, deletion or 
update of the object on a particular tag t. These are 
handled by the following methods. 

To install an object, one needs to call the following 
method on the object manager object f2. Depending 
on requirements, one may decide that further permis- 
sion tokens are necessary, or instead require a specific 
permission token from the tag management object . 

InstallOhject (caller, i,o,k) : 
verify owner = caller ; 

verify that object with name i does not exist on the 
tag yet ; 

create a new object o with name i with class key k 

To update or delete an object, one needs to call one 
of the following methods on the object to be updated or 
deleted. Additional permission tokens from that object 
may be required. Only the owner of a tag can delete an 
object. 



UpdateObject ('ca//er, i, : 

update object with name i to o ; 
UpdateClassKeyf ca/fer, i, fcj : 

update the class key of object with name i to k ; 
DeleteObject ('ca/Zer, : 

verify owner = caller ; 

verify i ^ fl ; 

delete the object with name i ; 

Note that by implementing object management this 
way, objects can only be managed by domains that 

— have access to the tag because they are a member 
of its access set A, and 

— have the correct permission token for the tag man- 
agement object J7, issued using its class key k^- 

Note that the tag management object itself can also be 
updated this way (and in particular its key), but cannot 
be removed or created. When tags are created, a default 
tag management object is present on the tag. 

Also note that neither the tag owner nor the owner 
of the tag management object is capable of removing 
objects that they do not own, or do not have a delete 
permission for. In order to prevent tags becoming un- 
usable because of the multitude of objects installed on 
it, one might consider to extend the functionality of 
RelinquishTagOwnership to include the deletion of 
every object (except, of course, the tag management 
object) on the tag. 

8 Security analysis 

We first give a security analysis of the authentication 
protocol from Sect. 6 against the most important se- 
curity properties mentioned in that section. We then 
analyse the security of the method invocation protocol 
from Sect. 7.1. 

The adversary we consider has full control over the 
communication medium: he can block, intercept, dupli- 
cate, modify and fabricate arbitrary messages. He can, 
however, not create valid MACs for messages if he does 
not know the key, and cannot encrypt or decrypt mes- 
sages for which he does not know the symmetric key. 
The adversary can corrupt arbitrary tags and hence can 
know their full state including any keys they store. The 
adversary can also corrupt arbitrary readers. However, 
such readers are known to be corrupted and the system 
is notified of any such corruption. 

Let 7 be the security parameter (implicitly defined 
by the size of G (see 6.1) and the choice of the size of 
the symmetric keys). 

We first prove the security of the authentication pro- 
tocol. 
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Lemma 1 Let a reader from domain D call the Junc- 
tion AuthenticateR{sk]j , PKjj, fc^) which returns (tr, t'). 
Let tag t call AuthenticateT {) which returns {a',D'). 
Then a ~ a' only ift — t' and D = D' . No other entity 
not in domain D knows a. 

Proof Consider the protocol in Fig. 1. Suppose a ~ 
{s © s') = {s' © s) = a'. Then the reader accepted the 
message {q'; s}k' ■ Hence ka = {t'}kA computed by 
the reader equals k'^. As k'^ is retrieved from A[_D'] and 
kA is only known to D this proves D = D' 

Similarly the tag must have accepted the message 
{id' ; e; r'; q; S; s}k^ using its own key k'^. Again for ka = 
{t'}kA must have k'^ = ka- Because only t holds 
ka = {t}kA must have t ~ t' . 

To know a one needs to know both s and s. This re- 
quires one to know ka- Clearly t knows this. Otherwise, 
it requires one to know kA (and t). This is only known 
to members of D. This proofs the final statement of the 
lemma. □ 

Privacy after authentication or full re-encryption is 
guaranteed by the following lemma. 

Lemma 2 Let t be a tag, whose tag identifier t for do- 
main D gets re- encrypted from id to id' (either by au- 
thentication or by a full re- encryption). Let id" be the 
encrypted tag identifier for domain D of an arbitrary 
tag t' =i t. Then there exists no adversary (that has no 
access to the private keys of domain D ) with resources 
polynomially bounded in 7 that can decide whether id' 
and id" or id' and id are encrypted tag identifiers of 
the same tag. 

Proof In [18] it is shown that, given our use of ElGa- 
mal over our choice of group G, there does not exist 
an adversary with resources polynomially bounded in 
7 that can properly match the re-encryptions of two ci- 
phertexts with the original input ciphertexts. The ad- 
versary linking either id or id" with id' would trivially 
solve this problem too, and hence cannot exist either. 
□ 

Resilience to reader compromise is shown by the 
following lemma. 

Lemma 3 A reader from domain D reported stolen in 
epoch e cannot decide whether two tags that have suc- 
cessfully authenticated with an unstolen reader from do- 
main D in epoch e' > e corresponds with a tag observed 
before that authentication. 

Proof At the start of epoch e', we have e = e'. and all 
readers in domain D that are not reported stolen receive 
new epoch keys {sko' , PK'j^) that are stored in E[e]. If a 



tag authenticates with this reader, according to the pro- 
tocol, it receives a new encrypted identifier encrypted 
with the keys {sko ,PK'd). Let two tags meet such a 
reader, obtaining encrypted tag identifiers id'a and idj, 
in exchange for their old identifiers ida and id^. If sub- 
sequently these tags meet a reader from domain D that 
was reported stolen in epoch e < e', this reader does 
not own the key pair (sku' , PK'j-,) and hence cannot 
decrypt id'a or id'fj. Therefore, by Lemma 2, the reader 
cannot link the previous encrypted identifiers ida and 
idb. □ 

Finally, we show security of the method invocation 
protocol. 

Lemma 4 A tag t only executes a method f of class c 
with class key kc if a reader in domain D with 

— At[D\ ^ _L when it starts the session, and 

— permission token kcj^D,A = {/, D, ^}fcc with A > 
nowt (when the permission is verified) 

issued the command to the execute this method in the 
session it started. Moreover, the tag will do so at most 
once. 

Proof Checking the protocol, we see that a tag t exe- 
cutes method / on class c with class key kc when 

— it receives a message correctly encrypted and mac- 
cd with its session key s, containing the parameters 
and the expected message counter m4- 1, and before 
that 

— has received a message correctly encrypted and mac- 
ed with its session key s, containing /, c, Z\ and a 
permission token kcj^D,A = {f,D,A}k^ with A > 
nowt, and the expected message counter m. 

The authentication protocol guarantees (see Lemma 1) 
that only if D is a member of At when starting a ses- 
sion, the reader and the tag share the same session key 
s. Therefore, in the current session the tag only ac- 
cepts messages constructed by such a reader in domain 
D. This proves that it must have issued the command 
to the execute this method in the session it started, 
and also that it held the appropriate permission to- 
ken. Moreover, due to the use of message counters, the 
current session only accepts a particular message en- 
crypted for this session at most once. This proofs the 
final statement of the lemma. □ 



9 Concluding remarks and further research 

We have presented a model for a fine grained and dy- 
namic management of access permissions to RFID tags, 
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and we have presented privacy friendly protocols effi- 
ciently implementing this model. This efficiency is achie"v 
by avoiding a costly key search algorithm at the reader 
side. The price to pay is a little less privacy: tags can 
be traced in between successful authentications by le- 
gitimate readers. However, this is mitigated quite effec- 
tively by giving tag owners the possibility to re-encrypt 
tag identifiers at any point in time. 

Although the model accommodates a multitude of 
use cases, in the course of this research we have iden- 
tified several capabilities that our current implementa- 
tion lacks. 

— Access to tags and objects is bound to specific do- 
mains. A domain with certain permissions cannot 
delegate them to another domain. Instead new per- 
missions have to be requested from the tag owner 
and the class owner. 

— Although access to a tag can be revoked instan- 
taneously, permission tokens to access objects can- 
not be revoked (although their validity can be con- 
strained by using short validity periods). 

— Another approach to limit validity of permissions is 
to issue one-time only permission tokens that can 
be used exactly once to call a particular method on 
an object. 

— Domains are granted access to specific tags one by 
one by the respective tag owners. Permission tokens 
to call a method on an object are however not tag 
specific (unless each object of the same class is given 
a separate class (or rather object) key. 

— The distinction between a permission to access a 
tag and a permission to call a method on an object 
is confusing and perhaps unfortunate. This distinc- 
tion arises from two factors. First, access to a tag 
is issued by the current owner, and is maintained 
on the tag to allow immediate revocation of access. 
Moreover, the privacy friendly authentication pro- 
tocol needs to know which domains have access to 
the tag - hence tag related access control decisions 
are taken at a lower layer than object related access 
control decisions. 

— Finally, to re-encrypt an identifier, one needs to own 
the corresponding access key. This severely limits 
the options for owners to re-encrypt their tags. On 
the other hand, not requiring such an access key 
puts tags wide open to dcnial-of-service attacks that 
feed them with bogus identifiers. 

Further research is necessary to see whether these capa- 
bilities are truly necessary in real-life applications, and, 
if so, how these capabilities can be added efficiently. We 
welcome discussion and feedback on these issues. 
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